Mechanism of common authentication for both supervisor and guest clusters

ABSTRACT

This disclosure describes a computer implemented method for receiving authentication credentials identifying a user; identifying computing systems for which the user is authorized access to; and transmitting tokens granting access to the identified computing systems. In some embodiments, no two tokens of the transmitted tokens grants access to the same one of the identified computing systems. The user typically has access to a management tool configured to manage the transmission of the received tokens to the corresponding computing systems, thereby granting the user the ability to have seamless access to any of the computing systems associated with the user&#39;s authenticated identity.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/918,709, entitled “MECHANISM OF COMMON AUTHENTICATION FOR BOTHSUPERVISOR AND GUEST CLUSTERS,” filed on Jul. 1, 2020, the content ofwhich is hereby incorporated by reference in its entirety for allpurposes.

FIELD

The present disclosure relates generally to minimizing the number oftimes an administrator is asked to authenticate their credentials whenadministrating server clusters.

BACKGROUND

Administrators often find themselves managing multiple computing systemsand/or networks that can be distributed geographically and/or virtually.In order to avoid a situation in which a bad actor that has gained somelevel of access to one of the multiple computing systems is able toinfiltrate the rest of the computing systems, the administrators aregenerally asked to maintain large lists of sign-on credentials in orderto securely authenticate themselves as administrators to each of themultiple computing systems. This can become quickly unmanageable wherethe administrators are asked to monitor or administrate over hundreds ofcomputing systems. For this reason, a mechanism for providing theadministrators a secure but less burdensome way to access the multiplesystems without compromising security is desirable.

SUMMARY

This disclosure describes mechanisms for providing a user access tomultiple computing systems based on a single authentication.

A computer implemented method for authenticating a user is disclosed.The computer implemented method includes: receiving credentialsidentifying a user; authenticating the credentials identifying the user;identifying a first computing system and a second computing system theuser is authorized to access from a plurality of computing systems basedon the authentication of the credentials; and transmitting a first tokento the user that provides access to the first computing system and asecond token to the user that provides access to the second computingsystem. The first token does not provide access to the second computingsystem and the second token does not provide access to the firstcomputing system.

A non-transitory computer-readable storage medium storing instructionsconfigured to be executed by one or more processors of a computingdevice is disclosed. The execution of the instructions by the processorscause the computing device to carry out steps that include: receivingauthentication credentials identifying a user; authenticating thecredentials identifying the user; identifying a first computing systemand a second computing system the user is authorized to access from aplurality of computing systems based on the authentication of thecredentials; transmitting a first token to the user that provides accessto the first computing system; and transmitting a second token to theuser that provides access to the first computing system and the secondcomputing system. The first token provides more access to the firstcomputing system than the second token provides to the first computingsystem.

A computer system is disclosed and includes one or more processors; andmemory storing one or more programs configured to be executed by the oneor more processors, the one or more programs including instructions for:receiving authentication credentials identifying a user; identifyingcomputing systems from a plurality of computing systems the user isauthorized to access; and transmitting a first token to the user thatprovides access to a first computing system of the plurality ofcomputing systems and a second token to the user that provides access toa second computing system of the plurality of computing systems. Thefirst token provides access only to the first computing system.

Other aspects and advantages of the invention will become apparent fromthe following detailed description taken in conjunction with theaccompanying drawings which illustrate, by way of example, theprinciples of the described embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure will be readily understood by the following detaileddescription in conjunction with the accompanying drawings, wherein likereference numerals designate like structural elements.

FIG. 1 shows a diagram illustrating an exemplary server cluster suitablefor use with the embodiment described herein.

FIG. 2 shows another exemplary computing environment that includesmultiple server clusters in communication with a management server.

FIG. 3 shows an exemplary configuration illustrating how namespaces canhelp to organize a large number of workloads running across multiplesupervisor and guest clusters.

FIGS. 4A-4C shows a process by which a trusted authentication system isable to establish a delegated single sign-on system.

FIG. 5 shows a flow chart depicting a method for providing anauthenticated user secure access to multiple computing systems.

DETAILED DESCRIPTION

Certain details are set forth below to provide a sufficientunderstanding of various embodiments of the invention. However, it willbe clear to one skilled in the art that embodiments of the invention maybe practiced without one or more of these particular details. Moreover,the particular embodiments of the present invention described herein areprovided by way of example and should not be used to limit the scope ofthe invention to these particular embodiments. In other instances,hardware components, network architectures, and/or software operationshave not been shown in detail in order to avoid unnecessarily obscuringthe invention.

Administrators are generally trusted with broad access to the resourcesof multiple computing systems, servers and/or server clusters. For thisreason, owners of these resources expect the administrators to maintainunique credentials to avoid a situation in which a stolen set ofcredentials can be used for unauthorized access to a number of differentsystems.

One solution to this issue is when an administrator logs in to a trustedsystem, the trusted system can include a module that checks thecredentials provided by the administrator to identify the administratorand then generates tokens for each of the systems that the identifiedadministrator has access to. In this way, when the administratorattempts to access a particular system, a particular token that appliesonly to that particular system being accessed is transmitted to thatsystem. This configuration has the following advantages: (1) theadministrator is not required to enter new credentials to gain access tothe system; (2) a rogue administrator or another bad actor that hassomehow intercepted or stolen the transmitted token only gains access tothe particular system associated with the transmitted token; (3)attempts to improperly use the token can be more easily logged andtracked since each token is only used to gain access to particularsystems; and (4) since the administrator is only responsible formaintaining a single set of credentials in a single authenticationsystem, additional security measures such as more frequent passwordchanges, two factor authentication and biometric verification can be putin place without unduly burdening the administrator. It should be notedthat while this application will discuss the specific instance where anadministrator is being authenticated across multiple systems or serverclusters that the described embodiments may also apply to users withoutelevated privileges in a manner that reduces the likelihood of a user'saccess to multiple systems being compromised.

Another benefit of the disclosed authentication method is that thetrusted authentication system is in at least periodic communication withall the other systems for which it is configured to create and issuetokens. In some embodiments, the systems can take the form of supervisorclusters and guest clusters. Supervisor clusters use virtual machines(VMs) to implement both control plane nodes and compute objects managedby the Kubernetes® control plane. For example, Kubernetes® pods areimplemented as “pod VMs,” each of which includes a kernel and containerengine that supports execution of containers. The Kubernetes® controlplane of the supervisor cluster is extended to support VM objects inaddition to pods, where the VM objects are implemented using native VMs(as opposed to pod VMs). Guest clusters include a standard Kubernetes®control plane and associated nodes, as well as components forinterfacing the underlying supervisor cluster. The guest clusterexecutes within compute objects managed by the supervisor cluster (e.g.,native VMs or both native VMs and pod VMs) and utilizes networking andstorage exposed by the supervisor cluster. In this manner, a guestcluster is a virtual extension of an underlying management cluster(i.e., the supervisor cluster) The communication with the other systemsallows the trusted authentication system to assist in maintainingsecurity compliance for the systems for which it generates tokens. Forexample, if a guest cluster changes a security policy it can requestthat the trusted authentication system confirm that the trustedauthentication system will comply with or has already complied with thechanged security policy. In cases where the trusted authenticationsystem is unable to comply with the new security policy, the system withthe new security policy could suspend authorization for the trustedauthentication system to issue new tokens for the system until the newsecurity policy is met by the trusted authentication system.

These and other embodiments are discussed below with reference to FIGS.1-5 ; however, those skilled in the art will readily appreciate that thedetailed description given herein with respect to these figures is forexplanatory purposes only and should not be construed as limiting.

FIG. 1 shows a block diagram illustrating an exemplary server cluster100 suitable for use with the embodiment described in this disclosure.Server cluster 100 can include hosts 102, 112, 122 and 132. While a fourhost system is shown for exemplary purposes it should be appreciatedthat server cluster 100 could include a larger or smaller number ofhosts. Each host 102-132 includes host hardware 110-140, which caninclude a designated amount of processing, memory, network and/orstorage resources. In some embodiments, each of the hosts provide thesame amount of resources, and in other embodiments, the hosts areconfigured to provide different amounts of resources to support one ormore virtual machines (VMs) running on the hosts. Each of the VMs can beconfigured to run a guest operating system that allows for multipleapplications or services to run within the VM.

Each of hosts 102, 112, 122 and 132 are capable of runningvirtualization software 108, 118, 128 and 138, respectively. Thevirtualization software can run within a virtual machine (VM) andincludes management tools for starting, stopping and managing variousvirtual machines running on the host. For example, host 102 can beconfigured to stop or suspend operations of virtual machines 104 or 106utilizing virtualization software 108. Virtualization software 108,commonly referred to as a hypervisor, can also be configured to startnew virtual machines or change the amount of processing or memoryresources from host hardware 110 that are assigned to one or more VMsrunning on host 102. Host hardware 110 includes one or more processors,memory, storage resources, I/O ports and the like that are configured tosupport operation of VMs running on host 102. In some embodiments, agreater amount of processing, memory or storage resources of hosthardware 110 is allocated to operation of VM 104 than to VM 106. Thismay be desirable when, e.g., VM 104 is running a larger number ofservices or running on a more resource intensive operating system thanVM 106. Clients 140 and 150 are positioned outside server cluster 100and can request access to services running on server cluster 100 vianetwork 160. Responding to the request for access and interacting withclients 140 and 150 can involve interaction with a single service or inother cases may involve multiple smaller services cooperativelyinteracting to provide information requested by clients 140 and/or 150.

Hosts 102, 112, 122 and 132, which make up server cluster 100, can alsoinclude or have access to a storage area network (SAN) that can beshared by multiple hosts. The SAN is configured to provide storageresources as known in the art. In some embodiments, the SAN can be usedto store log data generated during operation of server cluster 100.While description is made herein with respect to the operation of thehosts 110-140, it will be appreciated that those of hosts 110-140provide analogous functionality, respectively.

FIG. 2 shows another exemplary computing environment 200 that includessupervisor clusters 202 and 204 in communication with a managementserver 206. In some embodiments, management server 206 can take the formof a vCenter Server that is able to communicate and performadministrative tasks to keep each of the cluster and hosts within theirrespective clusters functioning properly. In some embodiments, each ofsupervisor clusters 202 and 204 can include virtualization componentsand various hardware similar to those described in cluster 100 depictedin FIG. 1 ; however, for purposes of focus and clarity some of thosecomponents have been omitted from FIG. 2 . Supervisor cluster 202includes hosts 208, 210 and 212, however, it should be appreciated thata larger or smaller number of hosts could be included in each of thedepicted clusters. In particular, host 208 can include virtualizationsoftware that facilitates the creation of a master virtual machine (VM)212. Master VM 214 can operate on a modified Kubernetes framework thatallows it to govern and administer a number of VMs 216, pods 218 and/orguest clusters 220 running on one or more VMs. It should be noted thatthe master VMs do not have to run on a Kubernetes framework and thatthis is merely one exemplary implementation. Master VM 214 includesauthentication components that work in conjunction with managementserver 206 to form a trusted authentication system allowing for thesecure authentication of users and particularly administrators. In someembodiments, these authentication components can include tools forinteracting with and receiving sign-on credentials taking many forms.For example, sign-on credentials can be received from any of thefollowing: (1) a reader capable of transmitting credentials stored on anidentification badge, security card or electronic device; (2) one ormore biometric readers configured to scan and transmit one or moreidentifying features of a user by analyzing a user's retina, fingerprints and/or voice; and (3) a user input device configured to allow theuser to enter a username and password. Some services can require a userto submit multiple forms of authentication from one or more of theaforementioned categories.

Host 208 can run different types of workloads that include VMs 216 andpods 218. Pods 216 can run natively on virtualization softwareassociated with hosts 208, 210 and 212 of supervisor cluster 202. Pods216 are capable of supporting multiple containers within a nativeKubernetes environment. Supervisor cluster 202 can also be configured tosupport one or more guest clusters. Guest cluster 220 is shownsupporting a multiple workloads 226 that draw resources from any or allof the hosts included within supervisor cluster 202. It should be notedthat while guest cluster 220 is shown running workloads 226 as opposedto specific types of workloads, workloads 226 refer broadly to virtualconstructs such as containers, pods or VMs. Guest cluster 220 can bepositioned within a namespace 222 that provides an abstraction ontowhich administrators are able to attach policy. In some embodiments,this policy is applied to namespaces to help with establishingpermissions for one or more guest clusters. For example, supervisornamespace 228 can be configured to allow establishment of the samepermissions for both guest cluster 230 and guest cluster 232. In someembodiments, each of VMs 216, pods 218 and guest clusters 220/228/230can be configured with different security rules that allow usersdifferent levels of access to content hosted on the same host and/orserver. To support this type of functionality users are often requiredto provide credentials when initially accessing a different service. Insome embodiments, a service running on one VM or container may be ableto auto-scale across different hosts or clusters to give a user accessto another VM or container running the same service without requiringthe user to provide a new set of sign-on credentials.

FIG. 3 shows an exemplary configuration illustrating how namespaces canhelp to organize a large number of workloads being run across multiplesupervisor and guest clusters. Software-Defined Data Center 300 caninclude a management server configured to manage multiple clusters, suchas supervisor clusters 302 and 304. As depicted, the supervisor clusterscan include one or more hosts 306-314 that provide the computingresources necessary to drive various workloads including VMs, Podsand/or Guest Clusters. Supervisor cluster 302 is shown includingmultiple namespaces 316-322 for assisting with management of the variousworkloads running on supervisor cluster 302. Namespaces can spanmultiple hosts as shown by namespace 322. The namespaces can also beutilized to separate guest clusters 326 and 328 from other workloadsrunning on supervisor cluster 302. In some embodiments, thisconfiguration allows the namespaces to establish a default set ofpermissions for users or administrators related to guest clusters 326and 328 to be different than permissions for users needing to interactwith and/or administer over workloads running within namespaces 316-320.Furthermore, access permissions can also be configured to vary acrossnamespaces 316, 318 and 320.

FIG. 3 also shows how guest clusters 326 and 328 can include guest levelnamespaces 330, 332 and 334 for assigning permissions to workloadsrunning within the guest clusters. This can allow for multiplenamespaces to help define roles and permissions for users oradministrators primarily working within one of the guest clusters. Forexample, default permissions for a user or administrator primarilyworking with workloads within namespace 332, such as containersassociated with pod 336, could be affected by default rules of bothnamespaces 322 and 332. In this way, the namespaces allow implementationof a hierarchical permission structure. For example, in the case where afirst token is configured to provide an identity of a particular user toguest cluster 328, namespace 322 can have rules granting allauthenticated users of guest cluster 328 or namespaces 330 and 332access to a limited number of resources of supervisor cluster 302. Inthis way, use of the first token could grant the user limited access toassets of supervisor cluster 302 without having to provide a tokenidentifying the user to supervisor cluster 302. In the event the userhad greater access to supervisor cluster 302, a second token compatiblewith supervisor cluster 302 but not with guest cluster 328 could betransmitted directly to supervisor cluster 302 to identify the user tothe supervisor cluster 302 when the greater access to supervisor cluster302 is needed. In some embodiments, gaining access to supervisor cluster302 could provide limited access to assets of guest cluster 328 byvirtue of rules of namespace 330 or 332 authorizing the limited accesswithout directly verifying the identity of the user. In the describedconfiguration, the first token would not be accepted by or compatiblewith supervisor cluster 302 since the first token is setup specificallyto be recognized and accepted by guest cluster 328 even though the useridentified by the token is granted access to supervisor cluster 302.

FIGS. 4A-4C show a block diagram illustrating how a trustedauthentication system 400 that includes components positioned within asupervisor cluster control plane node 402 and a management server 404can be utilized to grant secure delegated single sign on access toservices running within computing environment 200 or software-defineddata center 300. Since management server 404 can be responsible formanaging multiple supervisor clusters, supervisor cluster control plane402 is shown as one of multiple supervisor cluster control plane nodes.Supervisor cluster control plane 402 can be positioned within one ofmaster VMs 214 as described in FIG. 2 . FIG. 4A shows how anadministrator/user 406 can be logged into a computing system running acluster management tool 408, such as kubectl, that allowsadministrator/user 406 to communicate and interact with trustedauthentication system 400 by transmitting credentials 410 to supervisorcontrol plane node 402. While administrator 406 is shown transmittingcredentials 410 to supervisor control plane node 402 it should be notedthat administrator could also transmit credentials 410 to anothersupervisor cluster control plane of computer environment 200 withsimilar results. Credentials sent using cluster management tool 408 cantake the form of a user name/password or biometric information thatpositively establishes the identity of administrator 402. Depending onthe security associated with the computing system multiple differenttypes of credentials may be required to satisfy security policies. Forexample, an administrator could be required to enter a username andpassword and also transmit biometric readings to supervisor clustercontrol plane 402 to confirm the administrator's identity to trustedauthentication system 400. While supervisor cluster control plane node402 receives these credentials, it acts as an authentication proxy byforwarding credentials 410 on to management server 404 for validation bya single sign on service running on management server 404. Whenmanagement server 404 receives credentials 410, management server 404 isconfigured to determine which clusters and workloads administrator 406has access to. In some embodiments, this access information can becompiled in an access list stored by management server 404 andperiodically updated through communication channels between at leastmanagement server 404, supervisor cluster control plane node 402 andother workloads making up computing environment 200. Management server404 then proceeds to create tokens granting administrator 406 access toeach of the identified clusters and/or workloads.

In some embodiments, prior to creation of tokens 412 security policiesfor each of the guest clusters and workloads can be determined orreconfirmed. Security policies for trusted authentication system 400will generally be set to whatever the strictest policies are from thevirtual constructs. In the case where trusted authentication system 400is incompatible with requirements of a particular security policy, theworkload or guest cluster with the incompatible security policy can beremoved from the delegated single sign-on system. In some embodiments,trusted authentication system 400 may also be configured to allowadministrators without the tools necessary to meet the securityrequirements of every one of the virtual constructs with which thetrusted authentication system 306 is in communication the option toreceive tokens for only a subset of the guest clusters or workloads withwhich trusted authentication system 400 is in communication.

FIG. 4B shows how after credentials 410 are validated in accordance withthe requisite security policies, management server 404 transmits tokens412 back to supervisor control plane node 402, which then forwardstokens 412 on to cluster management tool 408 where tokens 412 are storedfor use by cluster management tool 408. The number of tokens transmittedback to supervisor control plane node 402 can vary based on an identityof administrator 406. For example, an administrator with access tomultiple supervisor clusters and three guest clusters could be issuedfour tokens that include one token with full access to the supervisorclusters and three tokens having access to respective ones of the threeguest clusters. Generally, guest cluster associated tokens provide onlylimited access to supervisor cluster assets and other guest clusterassets so that a user gaining unauthorized access to an administratortoken is not able to gain elevated privileges to all of the clustersrunning within computing environment 200. While the aforementionedexample gives one way in which permissions granted by tokens can belimited, tokens can also be organized in other ways. For example, anadministrator can receive one key providing access to all supervisorcluster workloads and another key for accessing workloads running on allguest clusters being hosted within the computing environment. Thisconfiguration would prevent a guest cluster user or guest clusteradministrator with unauthorized access to an administrator token fromgaining elevated access to workloads running within one or more of thesupervisor clusters. Generally, administrator 406 receives multipletokens 406 that provide different levels of access to different portionsof the computing environment. For example, a first tokens 412 maycompletely prevent access to all of a particular cluster or workloadwhile a second token 412 provides full administrative access to thatparticular cluster. In other embodiments, the first token 412 providespartial access to the particular cluster while the second token 412provides full administrative access to the particular cluster.

Each of tokens 412 can include a private key providing access to secureinformation stored or accessible within the computing environment.Management server 404 will also repeatedly send updated tokens 412 toadministrator 406 by way of supervisor cluster control panel 402 priorto previously issued tokens 412 expiring. In addition to providingtokens 412 to administrator 406 management server 404 can also beconfigured to transmit a public signing key 414 to guest cluster node416. Guest cluster control plane node 416 can run within one of theguest master VMs associated with supervisor cluster control plane node402. Public signing key 416 can be configured to recognize and validatethe newly issued tokens 412 and any other valid tokens currently in usewithin the computing environment. While management server 404 is shownonly sending public key 414 to guest cluster plane node 416 it should beappreciated that in some embodiments any time a change is made to publickey 414 management server 404 would be configured to distribute publickey 414 to all of the control plane nodes located in the computingenvironment.

FIG. 4C shows cluster management tool 408 being used to transmit one oftokens 412 to guest cluster control plane node 416. It should be notedthat cluster management tool 408 can receive information about which oftokens 412 to use with each respective control plane node. In someembodiments, this information can be transmitted along with tokens 412and in other embodiments this information can be included asidentification information in each of tokens 412 allowing clustermanagement tool 408 to transmit tokens 412 corresponding to the clusteror clusters administrator 406 requests access to. FIG. 4C shows howpublic key 414 that was received by guest cluster control plane node 416from management server 404 can be processed by an authorization serviceof guest cluster control panel node to validate tokens 412. Validationof token 412 can include checking its expiration date/time, determiningan identity of the user associated with token 412 and determiningwhether token 412 provides access to the cluster for the identifieduser. In the case cluster management tool 408 sends the wrong token or auser with unauthorized access to token 412 sends token 412 to the wrongcluster, even when the identified user would normally have access to thecluster token 412 access to the cluster would still be denied.

FIG. 4C shows how a synchronization service running within supervisorcontrol plane node 402 can be configured to transmit namespace rolebindings 418 to guest cluster control plane node 416. In someembodiments, an API server running within guest cluster control planenode 416 can receive namespace role binding data 418 and transmit anyupdated namespace role binding data to an authorization service of guestcluster control plane node 416 in order to apply the correct permissionsfor users of the guest cluster. This communication path can also be usedto make updates for particular users or groups of users when manuallyupdated by an administrator such as administrator 406. It should benoted that trusted authentication system 400 can also help keepadministrator 406 connected to the various guest clusters and workloadsby notifying administrator 406 when any security policies have changedand require new or more detailed credentials be delivered to allowcontinued access for administrator 406. In this way, administrator 302can update the credentials as described in FIG. 4A prior to losingaccess to the system due to more stringent security policies. In someembodiments, administrator 406 can receive a notification stating anamount of time left to send updated credentials prior to administrator406 losing access to the guest cluster or workloads with elevatedsecurity policies.

FIG. 4C also shows how a log analytics module 420 can be incommunication with management server 404. In some embodiments, loganalytics module 420 can be configured to monitor authentication logs ofcomputing environment 200 for improper use of tokens 412. For example,when a log shows a token 412 that is authorized to access only the guestcluster associated with guest cluster control plane node 216 being usedto attempt to access the guest cluster associated with guest clustercontrol plane node 422, then a processing circuit of log analyticsmodule 420 can determine that the improper use of token 412 was likelyperpetrated by a user with access to the guest cluster associated withguest cluster control plane node 416 on account of that token 412 onlyhaving been authorized for use with that guest cluster. So in additionto preventing access to a workload or guest cluster not specificallyauthorized by a particular token 412, this described delegated accesssingle sign-on method also helps identify users attempting unauthorizedaccess to protected resources of computing environment 200. In someembodiments, log analytics module 420 can be configured to transmit logsidentifying unauthorized access attempts to trusted authenticationsystem 400. In response to the preceding example, trusted authenticationsystem 306 can be configured to adjust a level of trust associated withthe guest cluster associated with guest cluster control plane node 416until the cause of the unauthorized use of the token is determined. Insome embodiments, where a threshold number of unauthorized attempts aredetermined to have originated from users of a particular guest clusteror workload, that guest cluster or workload can be removed from thecluster on account of its trust level having dropped too far to justifythe continued security threat it represents. In some embodiments,trusted authentication system 400 includes a notification module that isconfigured to notify administrators of the offending guest cluster orworkload when these types of unauthorized accesses are detected. Thiscan allow for the administrators to tighten up security policies,resulting in improved security for the entire computing environment.

FIG. 5 shows a flow diagram 500 illustrating a method for securelyproviding access to multiple resources of a computing system. The methodcan be performed by a trusted authentication system hosted on a servercluster that has been delegated permission to grant access to multipleresources on the server cluster and in some cases resources external tothe server cluster. At 502, a request for access to system resources isreceived accompanied by authentication information identifying a user ofthe computing system. The authentication information can include one ormore pieces of information including, e.g., user name and password,biometric scans, two factor authentication, scans of an access card andthe like. At 504, once the authentication information has been confirmedto properly identify the user, the trusted authentication system cancontact the multiple resources it has been granted access to, in orderto determine which resources the user has been granted access to. Insome embodiments, this information can be cached on the trustedauthentication system. In this way, the trusted authentication systemcan identify which computing systems the user is authorized to access.At 506, the trusted authentication system generates tokens associatedwith the computing systems it is in communication with that have grantedaccess to the authenticated user and that provide access only to aspecific computing system for a limited period of time. For example, aparticular token might grant the holder of the token access to aparticular computing system for an hour or two after which the trustedauthentication system would be responsible for delivering an updatedtoken to allow the user to continue interacting with the particularcomputing system. The granting and updating of tokens may be transparentto the user as system processes can be configured to continuously ensurethe user is able to continuously access the computing systems for whichthe user has been granted access.

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the describedembodiments. However, it will be apparent to one skilled in the art thatthe specific details are not required in order to practice the describedembodiments. Thus, the foregoing descriptions of specific embodimentsare presented for purposes of illustration and description. They are notintended to be exhaustive or to limit the described embodiments to theprecise forms disclosed. It will be apparent to one of ordinary skill inthe art that many modifications and variations are possible in view ofthe above teachings.

What is claimed is:
 1. A computer implemented method for authenticatinga user, the computer implemented method comprising: receivingcredentials identifying a user; authenticating the credentialsidentifying the user; identifying a first computing system and a secondcomputing system the user is authorized to access from a plurality ofcomputing systems; and transmitting a first token and a second token tothe user in response to identifying the first computing system and thesecond computing system, wherein the first token provides access to thefirst computing system and the second token provides access to thesecond computing system, wherein the first token provides a first amountof access to the first computing system and the second token provides asecond amount of access to the first computing system that is differentthan the first amount of access.
 2. The computer implemented method asrecited in claim 1, wherein identifying the plurality of computingsystems comprises communicating with the plurality of computing systemsto determine which of the plurality of computing systems the user isauthorized to access.
 3. The computer implemented method as recited inclaim 2, wherein access to the first computing system is based at leastin part upon roles defined by a namespace within which the firstcomputing system resides.
 4. The computer implemented method as recitedin claim 3, further comprising synchronizing namespace role bindingswith the first computing system.
 5. The computer implemented method asrecited in claim 1, wherein the first computing system comprises aplurality of workloads running within a supervisor cluster and thesecond computing system comprises a guest cluster.
 6. The computerimplemented method as recited in claim 1, further comprisingtransmitting a third token to the user that provides access to both athird computing system and a fourth computing system that share the samenamespace.
 7. The computer implemented method as recited in claim 1,further comprising: receiving an updated security policy from at leastone computing system of the plurality of computing systems; and when theuser has an active token granting access to the at least one computingsystem and the updated security policy is stricter than any ofpreviously established security policies, requesting the user providenew authentication credentials conforming with the updated securitypolicy.
 8. The computer implemented method as recited in claim 7,further comprising: transmitting a notification to the user informingthe user of when the active token granting access to the at least onecomputing system will expire if the new authentication credentials arenot received.
 9. The computer implemented method as recited in claim 1,further comprising: receiving log data from a log analytics systemshowing the first token issued to the user granting access to the firstcomputing system has been used in an attempt to access a third computingsystem that the first token is not configured to grant access to; andreducing a trust level for the first computing system, wherein the firstcomputing system is a guest cluster and the computer implemented methodfurther comprises transmitting a notification to the guest clusterinforming the guest cluster of a reason for reducing the trust level.10. The computer implemented method as recited in claim 1, wherein thefirst token is configured to identify the user to the first computingsystem, and the first computing system is configured to provide accessto the user in accordance with the identity of the user provided by thetoken.
 11. A non-transitory computer-readable storage medium storinginstructions configured to be executed by one or more processors of acomputing device cause the computing device to carry out steps thatinclude: receiving credentials identifying a user; authenticating thecredentials identifying the user; identifying a first computing systemand a second computing system the user is authorized to access from aplurality of computing systems based on the authentication of thecredentials; transmitting a first token and a second token to the userin response to identifying the first computing system and the secondcomputing system, wherein the first token provides access to the firstcomputing system and the second token provides access to the secondcomputing system, wherein the first token provides more access to thefirst computing system than the second token provides to the firstcomputing system.
 12. The non-transitory computer-readable storagemedium as recited in claim 11, wherein the steps further include:periodically communicating with the plurality of computing systems todetermine which of the plurality of computing systems the user still hasauthorization to access; transmitting updated tokens to the user forcomputing systems that the user is determined to still have access; andtransmitting new tokens to the user that provide access to computingsystems that the user is determined to have gained access.
 13. Thenon-transitory computer-readable storage medium as recited in claim 12,wherein the tokens transmitted to the user are stored in a datarepository that allows the user to access the computing systems the useris authorized to access.
 14. The non-transitory computer-readablestorage medium as recited in claim 12, wherein none of the updatedtokens provide access to the same computing system.
 15. Thenon-transitory computer-readable storage medium as recited in claim 11,wherein authenticating the credentials identifying the user comprisesconfirming the received credentials comply with security policiesassociated with the identified computing systems; and whereinidentifying computing systems from the plurality of computing systemscomprises receiving lists of authorized users from the plurality ofcomputing systems.
 16. A computer system, comprising: one or moreprocessors; and memory storing one or more programs configured to beexecuted by the one or more processors, the one or more programsincluding instructions for: receiving credentials identifying a user;authenticating the credentials identifying the user; identifying a firstcomputing system and a second computing system the user is authorized toaccess from a plurality of computing systems based on the authenticationof the credentials; and transmitting a first token and a second token tothe user in response to identifying the first computing system and thesecond computing system, wherein the first token provides access to thefirst computing system and the second token provides access to thesecond computing system, wherein the first token provides a first amountof access to the first computing system and the second token provides asecond amount of access to the first computing system that is differentthan the first amount of access.
 17. The computer implemented method asrecited in claim 16, wherein the computer system includes a trustedauthentication system running in a master virtual machine positioned ina first server cluster.
 18. The computer implemented method as recitedin claim 17, wherein the first computing system is located in the firstserver cluster and the second computing system is positioned in a secondserver cluster.
 19. The computer implemented method as recited in claim17, wherein the first computing system and the second computing systemare both positioned in the first server cluster.
 20. The computerimplemented method as recited in claim 18, wherein the first and secondserver clusters are managed by the same management server.